The present invention relates generally to the execution of scheduled jobs and more specifically to the management of the automated execution of scheduled jobs.
In existing systems that execute scheduled jobs, these jobs are commonly referred to as batch processes. In some UNIX processing environments, these scheduled jobs are also referred to as chron jobs. These batch processes are typically executed at off-times when processing requirements for a main system are reduced. For example, batch processes may be performed during late nighttime and early morning hours when system users are not accessing a central processing system. Therefore, the processing system may readily dedicate the needed processing resources for completing the batch processes or scheduled jobs.
Increased computing resources and system efficiencies have reduced the time-sensitive nature of batch processing. While many batch processes are run during off-peak hours, the timing of these processes are typically currently dictated by other means, such as the availability and time-sensitivity of the data being processed. For example, a batch process might be running a month-end report including billing information for multiple clients or customers. The scheduled execution of the job is based on the timing of the billing information being received in the processing system. In this example, the job is scheduled based on a reasonable determination of when the requisite billing information is available from the billing system.
Scheduled jobs are also complicated by the increased complexity of multiple processing systems. When a processing environment includes one or more processing systems capable of running the batch processes and multiple ancillary systems that provide the data for these jobs, problems can arise. If there is an error with any one of the multiple different processing systems in the processing environment, this may make the batch process incorrect. In addition to problems or errors in the ancillary system, there may also be concerns that these ancillary systems do not yet have complete and proper data sets, e.g. not all the requisite information in compiled yet. For example, if the batch process includes multiple invoices and one billing system does not have current invoice data, the scheduled job will run an improper report. In fact, the scheduled job will most likely have to be re-executed when the missing data is properly assembled or compiled. Improperly running scheduled job is not only extremely inefficient, but a significant waste of processing resources.
As the number of interdependent systems increases, there are also other concerns besides the integrity of the data used for the scheduled job. For example, if one system goes down for any reason, that may cause significant disruptions in the complete processing environment for one or more scheduled jobs, including further scheduled jobs that are dependent upon the generated data of previous jobs. As multi-processing environments globally interconnect, the potential for confusion in scheduled jobs increases.
In current processing systems, scheduled jobs are either executed or cancelled. There does not exist any system for managing these scheduled jobs, where the management includes monitoring the veracity of the data used for the job. If a job is scheduled for a predetermined time, that job is then executed at said time. Should there be concerns about the integrity of the data processing in the schedule job, a user must manually over-ride a job scheduling system to terminate the job. Another option is that a user may manually reset an execution time for a particular job, but this requires resetting the defined execution time for the job. When this occurs, a user must thereupon reset the job execution time back to its original time after the job is executed.
Although, in current processing systems, there does not exist indicators as the veracity of the data being processed. Rather, these systems merely assume the data is correct. If there is problem with a system, the user must be notified manually and must manually intercept the timed-execution of the scheduled job. For example, with multiple processing systems in multi-processing environments, there is no known mechanism for notifying the user that one or more data sets are not the proper data. For example, if one of the systems goes down, the batch processing system is unaware of having inaccurate data for the subsequent scheduled job. When data is retrieved from multiple systems, the batch process simply retrieves and processes the information, assuming the information is current and correct. As noted above, in the event one or more systems do not provide the proper data, the batch process is still executed, generating improper results and the job must be re-executed.